Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BDsensor: adding support for new probe sensor BDsensor #6490

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

markniu
Copy link

@markniu markniu commented Feb 10, 2024

adding support BDsensor for Fast auto bed leveling leveling.
About BDsensor:
It can measure the bed distance at any point in real time without moving the z axis up and down.
now the fast auto bed leveling is stable for pull, there will be more new features like real time adjust and strain gauge in the future.https://github.com/markniu/Bed_Distance_sensor
Config: https://github.com/markniu/Bed_Distance_sensor/wiki/Installing-for-Klipper

@Sineos
Copy link
Collaborator

Sineos commented Feb 11, 2024

Thanks a lot for your contribution. Please also provide the signed off as per point 3 in "What to expect in a review" in master/docs/CONTRIBUTING.md

Also, it would need to come with an update of the documentation in the relevant chapters, e.g. "bed level" and "g-codes"

Copy link

@slaesh slaesh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cant review/test in a technical perspective.. just some code-quality/hygiene hints :)

I guess this project could need some proper linting rules ;)

src/BD_sensor.c Outdated
uint32_t delay_m = 20, homing_pose = 0;
int sda_pin = -1, scl_pin = -1, z_ofset = 0;
uint16_t BD_Data;
//extern uint32_t timer_period_time;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can be removed? =)

src/BD_sensor.c Outdated

///////////BDsensor as endstop
struct timer time_bd;
#include "autoconf.h"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe move it up to all other imports?

src/BD_sensor.c Outdated
Comment on lines 165 to 166
}
void ndelay_bd(uint32_t nsecs)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
}
void ndelay_bd(uint32_t nsecs)
}
void ndelay_bd(uint32_t nsecs)

src/BD_sensor.c Outdated
ndelay_bd_c(nsecs);
}

unsigned short BD_Add_OddEven(unsigned short byte)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a little bit confusing to name a "short" byte =)) was wondering how a byte can have more than 8 (10) bits looking at the loop :)

src/BD_sensor.c Outdated
Comment on lines 232 to 233
}
void BD_i2c_stop(void)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
}
void BD_i2c_stop(void)
}
void BD_i2c_stop(void)

src/BD_sensor.c Outdated
uint16_t BD_i2c_read(void)
{
uint16_t b = 1024;
// if(BD_read_flag==1014)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can be removed? :)

src/BD_sensor.c Outdated
else
b=1024;

#if 0
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can be removed? or maybe add a speaking comment why this is present :)

src/BD_sensor.c Outdated
uint8_t data[8];
uint16_t BD_z;

//if(BD_read_flag==1018)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can be removed?

{
int addr=atoi((char *)args[2]);
BD_read_flag=addr;
if(addr==1015)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe all these const's should be an enum? 1015, 1023, 1024, .. so many number all over the place :))

Copy link

github-actions bot commented Mar 1, 2024

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

  1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
    If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
  2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
  3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

@KevinOConnor
Copy link
Collaborator

Thanks. Is this sensor based on the ldc1612 chip? There has been some work done on that chip at #6536 (and #6537).

My high-level feedback is that I think we need to integrate these efforts into a single "probe_eddy_current.py" type of module. I think we want to avoid having each probe implement their own implementations of PROBE, PROBE_ACCURACY, homing, etc.

-Kevin

@KevinOConnor KevinOConnor added the pending feedback Topic is pending feedback from submitter label Mar 21, 2024
@markniu
Copy link
Author

markniu commented Mar 22, 2024

hello Kevin, thanks!
this sensor is not based on ldc1612 chip, it is based on the TCA355G that is a traditional inductive proximity switch sensor chip, some other DAC chip and analog electrical component to change the eddy current, not like the ldc1612 which change the eddy frequency to measure the distance.

beside it can output the distance value or raw DAC data via the i2c port, it can also work as a switch sensor (just output low/high level in the sda pin) while homing, that helps to consumes low mcu usage.

with the new feature nozzle collision sensing that use the raw DAC value to adjust the z_offset automatically.

Thanks. Is this sensor based on the ldc1612 chip? There has been some work done on that chip at #6536 (and #6537).

My high-level feedback is that I think we need to integrate these efforts into a single "probe_eddy_current.py" type of module. I think we want to avoid having each probe implement their own implementations of PROBE, PROBE_ACCURACY, homing, etc.

-Kevin

@markniu
Copy link
Author

markniu commented Mar 22, 2024

I agree, and it is no problem to remove the PROBE and PROBE_ACCURACY in the BDsensor.py and use the PROBE, PROBE_ACCURACY in the probe.py.

@KevinOConnor KevinOConnor removed the pending feedback Topic is pending feedback from submitter label Mar 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants